Generally, a ubiquitous service refers to a service that allows a user to receive a desired service in anywhere. Also, a ubiquitous web service is a technology that enables connection, combination, and use of various application services at any terminal and under any environment. Through such a ubiquitous web service, a web service provider and a web service requester can coexist in various ubiquitous environments, and if having only web service function any terminal can use the function of web service provider.
However, the conventional web service statically binds the web service provider and the web service requester. Therefore, if the web service provider side's information is changed, the web service requester side's information should also be changed accordingly. For example, in case a service provider provides a web service that provides an address upon receipt of a zip code, if its interface is modified, a web service requester that is using the service should be modified to be compiled again. Further, in case a service A cannot be used, although a service B provides the same service, the existing web service method can not recognize this and dynamically offer the service B substituting for service A to the web service requester.
Under the ubiquitous environment, more seamless and robust services should be provided compared to under the conventional computer environment, but the above-stated drawbacks have been a great obstacle to the ubiquitous environment.
FIG. 1 is a block diagram showing the configuration of a conventional web service system. Referring to FIG. 1, the conventional web service system includes a web service registry 100, a web service requester 110, and a web service provider 120.
The following is a description for the operation of the conventional web service system.
First of all, the web service provider 120 stores interface information, including WSDL (web service description language) files for services to be provided, in the web service registry 100 in step S15. And then, the web service requester 110 searches for a desired web service from the web service registry 100 and receives interface information required for using the desired web service in step S14.
Next, the web service requester 110 receives the desired web service from the web service provider 120 by using the interface information. At this time, message exchanges between web service requester 110, the web service registry 100 and the web service provider 120 are based on SOAP (simple object access protocol). Many communication message exchanges that are also based on SOAP are required between the web service requester 110 and the web service provider 120.
FIG. 2 illustrates a procedure in which the web service system shown in FIG. 1 provides web services.
Referring to FIG. 2, the web service provider 120 first stores WSDL files and metadata associated with its own services in the web service registry 100, and then the web service registry 100 notifies the web service provider 120 of the storage result upon storage request. Next, the web service requester 110 requests the web service registry 100 to search whether there is its desired web service therein, and the web service registry 100 provides the web service requester 110 with the search result.
Lastly, the web service requester 110 receives a web service in a manner that it requests a desired service by communication message exchanges with the web service provider 120 based on interface information of the web service provider 120 provided from the web service registry 100, and receives the result of web service requested to the web service provider 120.